USB 3.0 Link Layer Timer Adjustment to Extend Distance

ABSTRACT

Methods and devices for transmitting SuperSpeed information between a host device and a USB device via an extension medium are provided. Link partner relationships are established between the host device and an upstream facing port device, between the USB device and a downstream facing port device, and between the upstream facing port device and the downstream facing port device. While the link partner relationship between the upstream facing port device and the downstream facing port device is substantially compliant to the USB 3.0 Specification, the link partner relationship may use a configurable link layer acknowledgement timer to compensate for delays in transmission over the extension medium.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 13/843,630,filed Mar. 15, 2013, which claims the benefit of Provisional ApplicationNo. 61/639,044, filed Apr. 26, 2012, the entire disclosures of which areincorporated by reference herein.

BACKGROUND

USB is a peripheral interface for attaching a wide variety of computingdevices, such as personal computers, digital telephone lines, monitors,modems, mice, printers, scanners, game controllers, keyboards, storagedevices. The specifications defining USB (e.g. Intel et al., UniversalSerial Bus Specification, Revision 1.0, January 1996; updated asRevision 1.1 in September 1998; further updated as Revision 2.0 in April2000; further updated as Revision 3.0 in November 2008, and subsequentupdates and modifications—hereinafter collectively referred to as the“USB Specifications”, which term can include future modifications andrevisions) are nonproprietary and are managed by an open industryorganization known as the USB Forum.

The USB Specifications establish basic criteria that must be met inorder to comply with USB standards. One of ordinary skill in the artwill recognize many terms herein from the USB Specifications. Thoseterms are used herein in a similar manner to their use in the USBSpecifications, unless otherwise stated.

Under Revision 3.0 of the USB Specifications, SuperSpeed connections areprovided between devices that establish “link partner” relationshipswith each other. Though the specification does not mandate anyparticular maximum cable length, in practical terms the timing mandatesand signaling techniques require a regular copper cable used for aSuperSpeed connection between a host and a device to be at most 3 meterslong to properly support the SuperSpeed connection between the linkpartners. Therefore, a new method and apparatus are needed to optionallyallow for extension of a SuperSpeed USB device to a greater distancefrom the host to which it is coupled, such that SuperSpeed USB packetsmay be propagated between the host device and the USB device.

However, existing methods and systems have some limitations. Use ofthese methods and systems may still result in unstable system behaviorunder some conditions. For example, at extension lengths greater than 50meters the system ports may become unstable and cycle in and out of theRecovery state. System instability has also been observed during periodsof high traffic, when using multiple devices, and when usingnon-traditional media. Therefore, a new method and apparatus are neededto optionally allow for extension of a SuperSpeed USB device from thehost to which it is coupled, such that the system may consistentlyremain in a state where it may propagate SuperSpeed USB packets.

It may be desirable to provide a connection between a host device and aUSB device using a non-traditional medium that is not USB 3.0 compliant,such as an optical or electrical medium. If a medium is used that is notUSB 3.0 compliant, the USB 3.0 compliant hubs may malfunction and resultin overall unstable system behavior. Therefore, a new method andapparatus are needed to optionally allow for extension of a SuperSpeedUSB device from the host to which it is coupled, such that SuperSpeedUSB packets may be propagated through a non-USB compliant medium betweenthe host and the USB device.

SUMMARY

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This summary is not intended to identify key features ofthe claimed subject matter, nor is it intended to be used as an aid indetermining the scope of the claimed subject matter.

In some embodiments, a USB extension device is provided. The USBextension device comprises a USB physical layer interface, a remoteinterface, and a protocol engine. The protocol engine is configured toestablish a first link partner relationship with a device via the USBphysical layer interface; establish a second link partner relationshipwith a second USB extension device via the remote interface; transmit aheader packet received from the device via the USB physical layerinterface to the second USB extension device via an extension mediumaccessible via the remote interface; and receive a header packetacknowledgement from the second USB extension device; wherein the headerpacket acknowledgement is received at an elapsed time after the headerpacket transmission that is greater than a standard link layeracknowledgement timer without causing the second link partnerrelationship or the first link partner relationship to transition torecovery.

In some embodiments, a method of providing SuperSpeed communicationbetween a host device and a USB device over an extension medium isprovided. A first link partner relationship is established between anupstream facing port device (UFP device) and the host device. A secondlink partner relationship is established between a downstream facingport device (DFP device) and the USB device. A third link partnerrelationship is established between the UFP device and the DFP device. Avalue of a standard link layer acknowledgement timer of the first linkpartner relationship and of the second link partner relationship isthree microseconds, and a value of a configurable link layeracknowledgement timer of the third link partner relationship isconfigurable to be greater than three microseconds.

DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of thisinvention will become more readily appreciated as the same become betterunderstood by reference to the following detailed description, whentaken in conjunction with the accompanying drawings, wherein:

FIG. 1 is a block diagram that illustrates an exemplary embodiment of asystem for extending USB communication according to various aspects ofthe present disclosure;

FIG. 2 is a block diagram that illustrates further details of theupstream USB extension device and downstream USB extension deviceillustrated in FIG. 1;

FIG. 3 is a block diagram that illustrates an exemplary embodiment of aport device according to various aspects of the present disclosure;

FIG. 4 is a sequence diagram that illustrates exemplary communicationbetween a host device and a USB device using an upstream facing portdevice and a downstream facing port device connected by a non-USB 3.0compliant communication channel, according to various aspects of thepresent disclosure; and

FIG. 5 is a sequence diagram that illustrates exemplary link headerpacket communication and acknowledgement between a host device and a USBdevice using a UFP device and a DFP device, according to various aspectsof the present disclosure.

DETAILED DESCRIPTION

FIG. 1 is a block diagram that illustrates an exemplary embodiment of asystem 100 for extending USB communication according to various aspectsof the present disclosure. The system 100 includes a host device 102 anda USB device 108. Traditionally, the host device 102 and the USB device108 would be directly connected via a USB cable, and would communicatedirectly with one another via a protocol that conforms to a USBspecification, such as USB 1.0, USB 1.1, USB 2.0, or USB 3.0. ForSuperSpeed communication, the host device 102 and the USB device 108would typically be connected to each other at the link layer as linkpartners. As discussed above, once the host device 102 and USB device108 are separated by a non-USB communication medium issues may arisewith regard to the host device 102 and/or the USB device 108.

The host device 102 may be any type of computing device containing a USBhost controller or a downstream facing port. Some examples of suitablehost devices 102 may include, but are not limited to, a desktopcomputer, a laptop computer, a tablet computing device, a servercomputer, a set-top box, an audio head unit for an automobile, anembedded host, and/or the like. Likewise, the USB device 108 may be anytype of device capable of communicating via a USB protocol with a USBhost controller or otherwise having an upstream facing port. The exampleillustrated in FIG. 1 is a webcam, but some other examples of suitableUSB devices 108 may include, but are not limited to, a human interfacedevice such as a keyboard or mouse, a mass storage device such as aflash drive or external hard drive, a USB-capable medical device, aprinter, a USB hub, a wireless controller, and/or the like.

In the present system 100, the host device 102 is connected via a USBprotocol to an upstream USB extension device 104, and the USB device 108is connected via a USB protocol to a downstream USB extension device106. The upstream USB extension device 104 and the downstream USBextension device 106 are communicatively coupled via a extension medium90 that may increase the distance between the host 102 and the USBdevice 108 beyond that supported by the USB specification. The extensionmedium 90 and communication thereon may include any suitable networkingtechnology, such as Ethernet, Bluetooth, WiFi, WiMax, the Internet,serial communication, and/or the like, and any suitable communicationmedium, such as via physical cables, via wireless spectrum, viafiber-optic cable, and/or the like. In some embodiments, the upstreamUSB extension device 104 and the downstream USB extension device 106 mayhappen to be closer to each other than the short USB requirementdistance, but may nevertheless communicate via the extension medium 90.

FIG. 2 is a block diagram that illustrates further details of theupstream USB extension device 104 and downstream USB extension device106 illustrated in FIG. 1. The upstream USB extension device 104includes an upstream facing port 202, and the downstream USB extensiondevice 106 includes a downstream facing port 204. As used herein, theterms “upstream facing port” and the corresponding acronym “UFP” may beused interchangeably, as may the terms “downstream facing port” and thecorresponding acronym “DFP.” Likewise, the upstream USB extension device104 is interchangeably described as an upstream facing port device orUFP device, and the downstream USB extension device 106 isinterchangeably described as a downstream facing port device or DFPdevice. The UFP 202 is configured at least to communicate with the hostdevice 102 via a USB-standard-compliant protocol, and to exchange USBbus traffic and other signals with the DFP 204. The DFP 204 isconfigured at least to communicate with the device 108 via aUSB-standard-compliant protocol, and to exchange messages and USB bustraffic with the UFP 202. The upstream USB extension device 104 and thedownstream USB extension device 106 may contain further components suchas a power supply, a status LED, a loudspeaker, an input device forswitching between UFP functionality and DFP functionality, and/or thelike. Since such components and their functions are familiar to those ofordinary skill in the art, they have not been discussed further herein.

As illustrated in FIG. 2, the upstream facing port 202 of the upstreamUSB extension device 104 is connected to a downstream facing port of ahost device 102, and the downstream facing port 204 of the downstreamUSB extension device 106 is connected to an upstream facing port of aUSB device 108. In other embodiments, the upstream facing port 202 ofthe upstream USB extension device 104 may be connected to a downstreamfacing port other than one provided by a host device 102, such as adownstream facing port of a hub and/or the like. Likewise, in otherembodiments, the downstream facing port 204 of the downstream USBextension device 106 may be connected to an upstream facing port otherthan one provided by a USB device 108, such as an upstream facing portof a hub and/or the like. The discussion below is primarily in terms ofthe simple topology illustrated in FIG. 2, but one of ordinary skill inthe art will recognize that in some embodiments similar techniques maybe used in other topologies without departing from the scope of thepresent disclosure.

FIG. 3 is a block diagram that illustrates an exemplary embodiment of aport device 300 according to various aspects of the present disclosure.In some embodiments, the port device 300 may be constructed to provideservices of an upstream facing port 202, and in some embodiments theport device 300 may be constructed to provide services of a downstreamfacing port 204. In some embodiments, the port device 300 may includeinstructions to provide services of both an upstream facing port 202 anda downstream facing port 204, wherein the particular port services thatare provided are determined by a user configuration such as a jumperswitch, a firmware setting, and/or the like.

As illustrated, the port device 300 includes a protocol engine 302, aUSB physical layer interface 304, and a remote interface 306. In someembodiments, the protocol engine 302 may be configured to provide and/orexecute the logic discussed below with regard to the UFP 202 and/or theDFP 204. The protocol engine 302 may instruct the USB physical layerinterface 304 to apply the appropriate electrical signals to the USBphysical layer in order to communicate with the USB device 108 or thehost 102. Likewise, the protocol engine 302 may instruct the remoteinterface 306 to exchange information with the remote USB extensiondevice.

In some embodiments, the protocol engine 302 may be implemented within alogic device such as a PLD, an ASIC, a FPGA, and/or the like. In otherembodiments, the protocol engine 302 may be implemented within acomputing device having at least one processor and a memory containingcomputer-executable instructions that, if executed by the at least oneprocessor, cause the protocol engine 302 to perform the actionsdiscussed below; a dedicated digital hardware device implemented, forexample, as a state machine configured to perform the actions described;within an application specific processor; and/or within any othersuitable computing device.

In some embodiments, logic of actions attributed to a USB extensiondevice is executed by a protocol engine 302, which then instructs a USBphysical layer interface 304 and/or a remote interface 306 to performthe appropriate communication steps associated with the logic.Throughout the discussion below, such actions may simply be described asbeing performed by the UFP 202 or the DFP 204 as if it was a singledevice for ease of discussion. One of ordinary skill in the art willrecognize that actions attributed directly to the UFP 202 or the DFP 204may actually be performed by a protocol engine 302, a USB physical layerinterface 304, a remote interface 306, and/or some other component ofthe USB extension device.

In some embodiments, the UFP 202 and DFP 204 may be configured tooperate in one of a plurality of modes, depending on the latency of thelink between them. In a low latency mode, the UFP 202 and DFP 204 may belinked by a communication channel of adequate speed to support aSuperSpeed USB 3.0 connection simply by bridging USB packets across thecommunication channel. In a medium latency mode, the UFP 202 and DFP 204may use a first technique to compensate for the delay in packettransmission between the UFP 202 and the DFP 204, and in a high latencymode, the UFP 202 and the DFP 204 may use a second technique tocompensate for the delay in packet transmission. In some embodiments,the mode may be selected by a user while configuring the UFP 202 and theDFP 204. In some embodiments, the UFP 202 and DFP 204 may automaticallydetermine a degree of latency between the devices and may automaticallychoose a mode based on that determination.

In some embodiments, SuperSpeed communication between the host device102 and the USB device 108 via the UFP device 104 and the DFP device 106may be supported at the link layer of the USB 3.0 protocol stack byestablishing one or more modified link partnerships to replace standardlink partnerships that would otherwise be created in a standardSuperSpeed connection between the host device 102 and the USB device108. For example, a link partnership may be established between the hostdevice 102 and the UFP device 104, and a link partnership may beestablished between the DFP device 106 and the USB device 108. Further,even though the UFP device 104 and the DFP device 106 may communicatewith each other at a physical level and/or protocol level usingnon-standard techniques, a link partnership may be established betweenthe UFP device 104 and the DFP device 106 at the link layer(point-to-point) that is substantially similar to the link partnershipdescribed in the Universal Serial Bus 3.0 Specification, Revision 1.0(including errata and ECNs through May 1, 2011), issued Jun. 6, 2011,and hereby incorporated herein by reference in its entirety for allpurposes (hereinafter “USB 3.0 Specification”).

Link layer related issues that arise in supporting a link partnershipbetween the host device 102 and the USB device 108 across a non-USB 3.0extension medium may be addressed using a modified link partnermanagement technique. The protocol engine 302 of the UFP device 104 andthe DFP device 106 may include a link partner management engine. Thelink partner management engine allows link management packets to bepassed from the host device 102 to the USB device 108 via the extensionmedium 90.

A link partner management engine may be present on one or both ends ofthe extension medium 90. The link partner management engine of a firstdevice generates a command in response to receiving a link managementpacket. The command is transmitted over the extension medium 90 and isreceived by a second device. The second device converts the command intoa link management packet corresponding to the link management packettransmitted by the first device. The link partner management enginegenerates a link management packet after receiving the commandcorresponding to receiving a link management packet.

FIG. 4 is a sequence diagram that illustrates exemplary communicationbetween a host device 102 and a USB device 108 using an upstream facingport device (UFP device) and a downstream facing port device (DFPdevice) connected by a non-USB 3.0 compliant communication channel,according to various aspects of the present disclosure.

At point 1 the host transmits a link management packet to the UFPdevice. At point 2, the UFP device converts/generates the linkmanagement packet into a command/message to be transmitted over thenon-USB 3.0 compliant medium. The DFP device receives the message, andin response to the received command, the DFP device generates a linkmanagement packet based on the received command/message from the UFPdevice. At point 3, the DFP device transmits the generated linkmanagement packet to the USB device 108.

The link partner management engines of the UFP device 104 and the DFPdevice 106 may be configured to establish standard link partnershipsbetween the UFP device 104 and the host device 102, and between the DFPdevice 106 and the USB device 108, respectively, and to manage trafficbetween each other over the extension medium 90. Some examples ofsimilar management of USB communication between a UFP device and a DFPdevice are described in commonly owned, co-pending U.S. patentapplication Ser. No. 13/683,993, filed Nov. 21, 2012, the entiredisclosure of which is incorporated herein by reference for allpurposes.

As stated above, the connection between the UFP device 104 and the DFPdevice 106 may include a link partnership that substantially complieswith the link layer (point-to-point) aspects of the USB 3.0Specification. The USB 3.0 Specification includes transmitter timers,including transmitter timers in the link layer (point-to-point). APENDING_HP_TIMER is specified in Section 7.2.4.1.10 for covering theperiod of time from when a header packet is sent to a link partner, towhen the header packet is acknowledged by a link partner, and isdescribed as causing the system to enter the Recovery state if the timergoes over 3 microseconds. If the transmitting link partner does notreceive a packet from the receiving link partner acknowledging atransmitted header packet within 3 microseconds, it will cause thesystem to enter the Recovery state, which may lead to unstable systembehavior and drastically reduced rates of data transfer. In embodimentsof the present disclosure where a substantially standard linkpartnership is established between the UFP device 104 and the DFP device106, such issues may arise frequently, as a high level of data trafficbetween link partners, a type of transmission media, any conversions ofthe data into another medium, or the physical distance between linkpartners could cause a link layer timer such as the standardPENDING_HP_TIMER to timeout and cause the system to enter the Recoverystate.

System instability caused by the timing out of the PENDING_HP_TIMER inan otherwise standard link partnership between the UFP device 104 andthe DFP device 106 may be eliminated by configuring the UFP device 104and the DFP device 106 to establish a link partnership thatsubstantially complies with the USB 3.0 Specification but for aPENDING_HP_TIMER with a timeout set at greater than 3.0 microseconds. Insome embodiments, the PENDING_HP_TIMER used by the UFP device 104 and/orthe DFP device 106 may be configurable to any desired value. In someembodiments, the PENDING_HP_TIMER may be disabled altogether. In someembodiments, other related timers, such as a CREDIT HP_TIMER, may alsobe configurable.

FIG. 5 is a sequence diagram that illustrates exemplary link headerpacket communication and acknowledgement between a host device 102 and aUSB device 108 using an UFP device 104 and a DFP device 106, accordingto various aspects of the present disclosure. In the illustratedsequence diagram, standard link partnerships are established between thehost device 102 and the UFP device 104, and between the DFP device 106and the USB device 108. A substantially standard link partnership isestablished between the UFP device 104 and the DFP device 106, but for aconfigurable PENDING_HP_TIMER. At point 1, the host device 102 transmitsa header packet to the UFP device 104. At point 2, the UFP device 104generates a header packet acknowledgement. The header packetacknowledgement may include a link command word such as an LGOOD orLBAD. As illustrated, an LGOOD is generated and transmitted to the hostdevice 102. It should be understood that other types of header packetacknowledgements may be generated and transmitted to the host device102. The specific header packet acknowledgement may be based on theheader packet received from the host device 102 and whether it isdetermined to be as expected and checked for errors or not.

In addition to transmitting a header packet acknowledgment, the UPFdevice 104 may transmit a link command indicating a level of buffercredits available, such as an LCRD_x command. The header packetacknowledgment and the buffer credit may be generated and communicatedto the host device 102 before the UFP device 104 receives anyacknowledgment related to the related information that it sends to theDPF device 106. One of ordinary skill in the art will recognize that thecommunication between the host device 102 and the UFP device 104 issimilar to standard communication between USB 3.0 link partners, and thetiming between the header packet transmission and header packetacknowledgement is less than the standard PENDING_HP_TIMER time of 3.0microseconds.

Once the UFP device 104 receives the header packet, the UFP device 104transmits the received header packet to the DFP device 106 via theextension medium 90. As described above, even though the UFP device 104and the DFP device 106 otherwise communicate at the link layer levelsubstantially as USB 3.0-compliant link partners, in some embodimentsthe header packet is converted into command or a message that may betransmitted over a non-USB compliant medium. For example, the signalcould be converted into the digital domain and transmitted over fiberoptic cable, coaxial cable, and/or any other suitable extension medium90.

At point 3, the DFP device 106 receives the header packet from the UFPdevice 104. Similar to the discussion above in relation to thecommunication between the UFP device 104 and host device 102 linkpartners, the DFP device 106 generates and transmits a header packetacknowledgement and buffer credit information to the UFP device 104.Though the UFP device 104 and DFP device 106 have otherwise beencommunicating at the link layer level substantially as USB 3.0-compliantlink partners, the UFP device 104 has been configured to wait longerthan the standard PENDING_HP_TIMER time, e.g., longer than 3microseconds, for the header packet acknowledgement, without entering arecovery state. A link partner connection between the UFP device 104 andthe DFP device 106 may therefore be maintained despite a transmission orprocessing delay related to traffic over the extension medium 90.

In some embodiments, the header packet acknowledgment and buffer creditinformation may be sent by the DFP device 106 before any buffer creditinformation or acknowledgment is received from the USB device 108, inorder to minimize the additional delay. At point 3, the header packet istransmitted by the DFP device 106 to the USB device 108. Based on thereceived header packet, the USB device 108 transmits a header packetacknowledgment and buffer credit information to the DFP device 106.

One of ordinary skill in the art will recognize that, althoughtransmission of a header packet from a host device 102 to a USB device108 is illustrated and described, embodiments of the present disclosuremay also support transmission of other types of link layer informationfrom the USB device 108 to the host device 102 in a similar way.Further, while the configurable PENDING_HP_TIMER has been used in theabove examples to provide for a greater delay in transmission than wouldcomply with the USB 3.0 Specification, in some embodiments, theallowable distance between the host device 102 and the USB device 108may be limited to less than that allowed by the USB 3.0 Specification bydecreasing the timeout setting of the PENDING_HP_TIMER. This may beuseful to provide added security or other features relating to limitingthe distance between the UFP device 104 and the DFP device 106.

While illustrative embodiments have been illustrated and described, itwill be appreciated that various changes can be made therein withoutdeparting from the spirit and scope of the claimed subject matter.

The embodiments of the invention in which an exclusive property orprivilege is claimed are defined as follows:
 1. A USB extension device,comprising: a USB SuperSpeed physical layer interface; a remoteinterface; and a protocol engine configured to: receive a header packetfrom a device via the USB SuperSpeed physical layer interface; transmita header packet acknowledgement to the device via the USB SuperSpeedphysical layer interface to be received at a time less than a standardlink layer acknowledgement time after the header packet was transmittedby the device; transmit the header packet received from the device viathe USB SuperSpeed physical layer interface to a second USB extensiondevice via an extension medium accessible via the remote interface;monitor an amount of time elapsed after transmitting the header packetto the second USB extension device; receive a header packetacknowledgement from the second USB extension device; compare themonitored amount of time to the standard link layer acknowledgementtime; and not causing a transition to a recovery state for a link layerconnection between the USB extension device and the second USB extensiondevice via the extension medium and not causing a transition to arecovery state for a link layer connection between the USB extensiondevice and the device via the USB SuperSpeed physical layer interface inresponse to determining that the monitored amount of time is greaterthan the standard link layer acknowledgement time.
 2. The device ofclaim 1, wherein the standard link layer acknowledgement time is aPENDING_HP_TIMER.
 3. The device of claim 1, wherein the extension mediumincludes fiber optic cable, coaxial cable, or wireless transmission. 4.The device of claim 1, wherein the extension medium includes apacket-based network, an Ethernet layer 2 network, or an Ethernet layer3 network.
 5. The device of claim 1, wherein the USB physical layerinterface includes an upstream facing port or a downstream facing port.6. A USB extension device, comprising: a USB SuperSpeed physical layerinterface; a remote interface; and a protocol engine configured to:transmit a link layer header packet received from the device via the USBSuperSpeed physical layer interface to the second USB extension devicevia an extension medium accessible via the remote interface; and receivea link layer header packet acknowledgement from the second USB extensiondevice; wherein the link layer header packet acknowledgement is receivedat an elapsed time after the link layer header packet transmission thatis greater than a standard link layer acknowledgement timer withoutcausing the second link partner relationship or the first link partnerrelationship to transition to recovery.
 7. The device of claim 6,wherein the standard link layer acknowledgement timer is threemicroseconds.
 8. The device of claim 6, wherein the extension mediumincludes fiber optic cable, coaxial cable, or wireless transmission. 9.The device of claim 6, wherein the extension medium includes apacket-based network, an Ethernet layer 2 network, or an Ethernet layer3 network.
 10. The device of claim 6, wherein the USB physical layerinterface includes an upstream facing port or a downstream facing port.11. A method, comprising: receiving, by a Universal Serial Bus (USB)extension device, a header packet from a device via a USB SuperSpeedphysical layer interface; transmitting, by the USB extension device, aheader packet acknowledgement to the device via the USB SuperSpeedphysical layer interface to be received at a time less than a standardlink layer acknowledgement time after the header packet was transmittedby the device; transmitting the header packet received from the devicevia the USB SuperSpeed physical layer interface to a second USBextension device via an extension medium accessible via a remoteinterface; monitoring an amount of time elapsed after transmitting theheader packet to the second USB extension device; receiving a headerpacket acknowledgement from the second USB extension device; and notcausing a transition to a recovery state for a link layer connectionbetween the USB extension device and the second USB extension device viathe extension medium and not causing a transition to a recovery statefor a link layer connection between the USB extension device and thedevice via the USB SuperSpeed physical layer interface in response todetermining that the monitored amount of time is greater than thestandard link layer acknowledgement time.
 12. The method of claim 11,wherein the standard link layer acknowledgement time is threemicroseconds.
 13. The method of claim 11, wherein the extension mediumincludes fiber optic cable, coaxial cable, or wireless transmission. 14.The method of claim 11, wherein the extension medium includes apacket-based network, an Ethernet layer 2 network, or an Ethernet layer3 network.
 15. The method of claim 11, wherein the USB SuperSpeedphysical layer interface includes an upstream facing port or adownstream facing port.